home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 204 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  5.0 KB
  1. Path: news.mindlink.net!news
  2. From: genew@mindlink.bc.ca (Gene Wirchenko)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.std.c
  4. Subject: Re: Hungarian notation
  5. Date: Sat, 27 Jan 1996 17:52:22 GMT
  6. Organization: MIND LINK! - British Columbia, Canada
  7. Message-ID: <4edore$sh1@fountain.mindlink.net>
  8. References: <30C40F77.53B5@swsbbs.com> <JSA.96Jan26175507@organon.com> <31098190.8106176@nntp.ix.netcom.com> <4eco1g$aih@fountain.mindlink.net> <4ecqkn$p1t@solutions.solon.com>
  9. NNTP-Posting-Host: line125.nwm.mindlink.net
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. seebs@solutions.solon.com (Peter Seebach) wrote:
  13.  
  14. >In article <4eco1g$aih@fountain.mindlink.net>,
  15. >Gene Wirchenko <genew@mindlink.bc.ca> wrote:
  16.  
  17.      My paragraphs are >> in this article.  I responded to not wrote
  18. the next paragraph.
  19.  
  20. >>>I claim that ISO 6.2.1.2 requires that an implementation actually do
  21. >>>such a conversion.  The implementor may choose the mapping.  Beside
  22. >>>the usual throwing away of high order bits, possibilities include
  23. >>>always using the value 0, or the largest possible value for the new
  24. >>>type, or, even, a random value.
  25.  
  26. >>     Implementation defined means implementation defined, not what you
  27. >>want it to mean.  I agree that your interpretation sets out reasonable
  28. >>actions that might be performed.  Please quote chapter and verse on
  29. >>where the Standard states that implementation defined actions must be
  30. >>"reasonable" (whatever the hell that is <G>).
  31.  
  32. >Ahh, but there is the key.
  33.  
  34. >My understanding (and I believe this is Mike's point) is that there is
  35. >a different between implementation defined *BEHAVIOR* and an implementation
  36. >defined *RESULT*.
  37.  
  38. >My understanding is that integer conversions are an implementation
  39. >defined *RESULT*.  No other *behavior* is allowed - the semantics do
  40. >not imply or show any.
  41.  
  42.      Is this defined in the Standard?
  43.  
  44. >This is as opposed to system(), which has implementation defined *behavior*
  45. >whenever system(NULL) returns non-zero.  In particular, an implementation
  46. >could provide a command interpreter that interpreted any string as the string
  47. >to write at the beginning of every block on a disk.  Such an implementation
  48. >would likely do poorly in the marketplace (unless Microsoft marketed it as
  49. >a new redundant filesystem), but would be legal.
  50.  
  51. >However, given something where the *result* is implementation defined, I
  52. >would expect that no unexpected *behavior* was allowed.
  53.  
  54.      A result is a behavior, no?
  55.      Gah, the arguments over wording.  Next: "How many angel can dance
  56. on the end of a C pointer?"
  57.  
  58. >This is similar to the special case where a failure to return a value from
  59. >main() results in an undefined *termination status* but is otherwise required
  60. >to behave sanely; streams must be flushed, et al.  (Another ghastly thing
  61. >in Schildt's C:TCR.  He says that fflush will clear the input buffer on
  62. >input streams.  *sigh*.)
  63.  
  64.      fflush(Schildt);
  65.  
  66. >>     Is your claim supported in the Standard?  If it isn't, you're
  67. >>wasting your time.  What if the conversion results in overflow?
  68.  
  69. >The point of explicitly stating that the *result* is imp-defined is to
  70. >*define the behavior*.
  71.  
  72. >Note that Appendix G states (wrongly) that a conversion that could overflow
  73. >results in undefined behavior.  This is only true of floating point ->
  74. >integral conversions.  (It is also true of operations other than
  75. >conversions.)
  76.  
  77. >>     Why are no side effects permitted?  Chapter and verse, please.
  78.  
  79. >Because none are specified.  The semantics of the >> operator on signed
  80. >ints are implementation specified (or is that defined?) but no one would
  81. >tolerate it formatting disks, because it doesn't say it can, and the
  82. >wording makes it clear that no extra behavior is expected.
  83.  
  84.      Doesn't none specified mean that the implementation is free to
  85. play hopscotch with nasal demons?
  86.  
  87. >>     What if the conversion results in overflow?
  88.  
  89. >This is actually a legitimate question; if conversion is taken to be
  90. >an operation, then the previously pointed out limit on all arithmetic
  91. >ops comes into play, and we have full-fleged *undefined behavior* -
  92. >easily enough to format a disk with.
  93.  
  94. >>     If it is impossible to convert due to sizing, then the "must" is
  95. >>rather silly, isn't it?
  96.  
  97. >Not really; it must do *some* conversion, and the conversion must be the
  98. >obvious one where that applies, and implementation-defined elsewhere.
  99.  
  100.      My point is that if the value can't be represented then it's
  101. hardly the case that a conversion is being performed.  If you consider
  102. butchering a value to an implementation defined value to be
  103. conversion, gah.
  104.  
  105. >>Right Hand of God.  So what about your claims!  If they can't be
  106. >>supported by the Standard, forget it.  Schildt CLAIMS that void main()
  107. >>is ok.
  108.  
  109. >Sadly, I am beginning to doubt that there is a true statement about C he
  110. >*doesn't* deny somewhere in that book.
  111.  
  112.      That would be too easy!
  113.  
  114. [sigsnip raised: remainder of message tossed]
  115.  
  116. Sincerely,
  117.  
  118. Gene Wirchenko
  119.  
  120. C Pronunciation Guide:
  121.      y=x++;     "wye equals ex plus plus semicolon"
  122.      x=x++;     "ex equals ex doublecross semicolon"
  123.  
  124.